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APPENDIX C 

The following examples illustrate the invention. 

Exemplary Scenarios for Reserving a Namespace 

The following examples illustrate reserving a namespace. 

Company A has just signed for NSP hosted services. Included in these services is e-mail 
as well as authentication system accounts. The administrator for A.com goes to the NSP web site 
and signs up to get these services on behalf of Company A. The NSP service begins a process by 
which they own the DNS records for the namespace (this might take up to 24 hours). Once that is 
accomplished, the NSP servers call a SOAP interface that the authentication system hosts and 
requests the namespace to be reserved. The namespace is reserved instantaneously. This means 
that only the NSP can create EASI accounts in this namespace. At the same time, creation of 
accounts via the authentication system registration page is disallowed. 

In another example, Company A has just signed up for an affiliate's service that includes 
authentication system accounts but no e-mail. The administrator for A.com goes to the affiliate's 
web site and signs up to get these services on behalf of the company. The affiliate begins a 
process by which they own the DNS records for the namespace (this might take up to 24 hours). 
Once that is accomplished, the affiliate's servers call a SOAP interface that the authentication 
system hosts and requests the namespace to be reserved. The namespace is reserved 
instantaneously. 

The only difference between the scenarios listed above is the e-mail provisioning in the 
first scenario. For the second scenario, the namespace is reserved just as in the case of first 
scenario, but there is no real "e-mail" that is provisioned. 
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Exemplary Scenarios for Releasing a Namespace 

The following example illustrates releasing a namespace. 

Company A, which was until now using services hosted by an NSP, decides that it no 
longer needs these services. The administrator of A.com goes to the NSP web page and informs 
the NSP service that Company A would like to cancel its service with the NSP. Among other 
things, the NSP tells the authentication system service that the accounts that were being managed 
by NSP on behalfofA.com are no longer the responsibility of NSP. Transparent to Company A 
(and A.com), all accounts in the namespace are now marked as not "managed". Fred, who is an 
employee of Company A, is now able to completely "own" his authentication system account. 

Exemplary Scenario for Creating a User Account Associated with a Namespace 
The following example illustrates creating a user account. 

After reserving a namespace, the administrator of A.com waits for a few hours and then 
goes to the NSP web site and starts creating accounts for the people inside the company. The 
administrator enters the names of the users on the web page provided by the NSP and selects a 
password on behalf of the user and then informs the user that the user must go to the 
authentication system member services page and change the secret question and answer (as a hint 
to the user to recall a forgotten password). The administrator enters a secret Q/A for the 
accounts. Behind the scenes, the NSP service sends a request to the authentication server to 
create these accounts. 

Exemplary Scenarios for Listing User Accounts Associated with a Namespace 

The following examples illustrate listing user accounts associated with a namespace. 

Fred works for Company A. He signed up for an authentication system account using his 

e-mail Fred@ A.com. A few weeks later, Company A starts using the services of NSP for e-mail 
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hosting. When the administrator tries to create authentication system accounts for everyone, the 
administrator can see a list of accounts already existing in the namespace. The administrator 
notices that Fred already has an account with the authentication system and does not create 
another account for him. The next time Fred tries to sign-in with his authentication system 
account, he is told that his account now falls within a managed namespace and that he must 
either consent to being in a managed namespace or change his sign-in name to one that does not 
belong to the managed namespace. Fred consents to staying in the managed namespace and can 
now use his account normally. 

The invention also includes the following modified scenarios using various combinations 
of the APIs of the invention. 

In the example above, if the administrator asks Fred if he already has an account, and 
does not create another account for him, then when Fred tries to sign-in, he is presented with a 
consent page informing him that in order to continue using the same sign-in name, he must 
consent to being managed. 

Alternatively, in the above scenario, the administrator will create another authentication 
system account for Fred (since the administrator has no way of knowing if Fred has an account). 
This will cause a forced change sign-in name on Fred's old account. The next time Fred tries to 
sign-in, he can do so with the account that he originally had (in which case he will be asked to 
change sign-in name) or he can sign in with the new account the administrator has created 
(which will need no consent). In this case, Fred decides to sign-in with the new account. Fred can 
recover his old identity (buddy lists, etc.) by changing his old account name to something else. 

Alternatively, Joe already has an authentication system account with the account name 
Joe@B.com. Now, as part of A.com, he is asked to create a new account Joe@A.com. Joe 
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would like to merge both accounts or at least be able to change the account name so that he has 
only one authentication system account that is Joe@A.com. The invention provides such 
functionality. 

In yet another example, Fred is part of Company A, which currently does not use the 
NSP. Fred's e-mail account is Fred@A.com and he signs up for an authentication system 
account with this e-mail. When he gets a validation mail (signaling creation of the account), he 
validates his account. Fred now leaves Company A, which deletes the e-mail address that Fred 
owned. Company A also starts using the NSP services. Now a new Fred joins the company and 
A.com would like to give the account name Fred@A.com to the new Fred. However, since they 
are now using the NSP for hosting e-mail, Company A needs to create an authentication system 
account with the sign-in name Fred@A.com. Since the namespace A.com is "managed" by NSP, 
the administrator of A.com creates a new EASI account by going to the NSP web page. The 
administrator gives the password for that account to the new Fred who will be able to use the 
account immediately. The old Fred will not lose his data associated with this authentication 
system account. 

Exemplary Scenario for Resetting a Namespace Password 

The following example illustrates resetting a namespace password. 

Fred has forgotten his password to his authentication system account. He goes to the 

administrator of his organization who in turn goes to the NSP web page, selects a password and 

resets the password for Fred. The administrator then supplies Fred with the new password. The 

administrator would not ask for Fred's country, region, zip code or ask him for the secret Q/A 

though he may be able to supply them. If Fred went to the authentication system support, he 
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would be told that they are unable to reset his password and that Fred needs to go to NSP support 
to be able to have his password reset. 



Exemplary Scenario for Updating a User Profile 

The following example illustrates updating a user profile. 

When an ASP creates an account, a mailbox is automatically setup for that user in the 
database. If that user does not use the account for 90 days, the ASP will de-activate the mailbox, 
and clear the bit in the database to indicate that the user does not have a mailbox anymore. 

Exemplary Scenarios for Changing a User Sign-In 

The following examples illustrate changing a user sign-in. 

Fred has an account Fred@authenticationsystem.com and decides that he would like to 
change his sign-in name to FredSmith@authenticationsystem.com. He goes to the member 
services page and clicks on the "change sign-in name" button that allows him to change his sign- 
in name. From now on, he uses the sign-in name FredSmith@authenticationsystem.com. 

In another example, Joe works for a company A and has an e-mail account Joe@A.com. 
He signs up for an authentication system account with this name. Company A decides to use the 
services of an NSP (e.g. NSP) for hosting its e-mail. The namespace A.com is now "managed" 
by the NSP. A few days later, Joe is fired. The administrator for A.com goes to the NSP web site 
and clicks on a button, which allows the administrator to de-provision the account Joe@A.com. 
The next time Joe tries to sign-in with the name Joe@A.com, the login page warns him that his 
account was part of a managed namespace and that Company A has decided to re-claim that 
name and that he must change his sign-in name to something other than ending in A.com. Joe 
types in a new name such as Joe@authenticationsystem.com. His profile information is intact. 
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From now on Joe uses the name Joe@authenticationsystem.com for all his authentication system 
sign in activities. 

In another example, Sue works for Company A and has an e-mail address Sue@A.com. 
She signs up for an authentication system account using that e-mail address. One day Sue 
decides to quit the company. When she leaves the company, her e-mail account is canceled but 
she carries on using the EASI account Sue@A.com. After a few months, Company A decides to 
use the services of an NSP for hosting e-mail. As part of the deal, everyone gets EASI accounts 
using the e-mail accounts they had. Soon, a new Sue joins the company. The administrator of 
A.com goes to the NSP web site and creates a new account Sue@A.com. The new Sue 
immediately starts using this account without any problems. A few days after the administrator 
created an account for the new Sue, the old Sue decides to check her account. She tries to sign-in 
with her sign-in name (Sue@A.com) but the login page tells her that her account is now part of a 
managed namespace and that her and in order to keep her account information, she will need to 
change her sign in name to something other than that belonging to the A.com namespace. She 
picks a new name Sue@authenticationsystem.com and types it in. She is immediately able to see 
her portfolio. From now on the old Sue uses the name Sue@authenticationsystem.com. 

In yet another example, Mary Smith works for Company A, which is using the services 
of an NSP for its e-mail needs. Her authentication system account (created by the NSP) is 
MarySmith@A.com, as is her e-mail. Mary now decides to get married and change her last 
name. She goes to the authentication system member services page and attempts to change her 
sign-in name but is told that she needs to go to her administrator to request the change. She goes 
to the administrator of the tompany A.com and asks the administrator to change her e-mail and 
authentication system account name to MarySlater@A.com. The administrator goes to the NSP 
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web site and makes this change on her behalf. Mary's e-mail and authentication system sign in 
name are now changed and she starts using her new account name MarySlater@A.com to access 
her account information such as her e-mail. 

In yet another example, Joe runs a small business and has a web site called 
JoesCoffee.com. He now wants to have his e-mail hosted by the NSP but is not entirely sure if 
he wants to start using the NSP services for a long period of time. So, he signs up for e-mail 
service hosted by NSP (e.g., A.com) and his e-mail address is Joe@A.com. After a few days, 
Joe finds that the e-mail service is reliable and offers value to him and he decides to ask his NSP 
to create his e-mail in a domain that he hosts. So he decides to change his sign-in name to 
Joe@JoesCoffee.com. He goes to the authentication system member services web page where he 
tries to change his sign-in name; he is informed that since this is a managed account, he must go 
to his administrator to request a change. He then goes to the NSP portal page where he requests 
that his sign-in name be changed from Joe@A.com to Joe@JoesCoffee.com. The request is 
processed immediately and from now on Joe's sign-in name is Joe@JoesCoffee.com. A few days 
later, Joe decided that he really does not like the e-mail service hosted by NSP for which he is 
paying a monthly fee. Instead he prefers the lower monthly fees charged if his e-mail address 
was Joe@A.com. So, he goes to the NSP portal web site and requests that his name be changed 
back to Joe@A.com. The change is processed instantaneously and from now on Joe's sign in 
name is Joe@A.com. 

In an alternative example, Joe's e-mail address is Joe@A.com, which he uses to sign up 
for an authentication system account. Now, Joe decides to change his e-mail provider. His e-mail 
address changes to Joe@B.com. Joe now goes to the authentication system member services and 
clicks on the change sign-in name link. He enters his new e-mail address. However, it turns out 
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me email address). Wh en j oe , 
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